Multi-modal navigation system and method

ABSTRACT

One or more embodiments may include a multi-modal navigation system and method. Route information may be received for generating a navigation route which may comprise multiple modes of transportation to a destination. GPS data may also be received. The navigation route to the destination across the multiple modes of transportation may be determined. The route may be updated as the route is traversed. The navigation route across the multiple modes of transportation may be output based on the GPS data.

BACKGROUND

1. Technical Field

Various embodiments relate to navigating a route using multiple modes oftransportation. In some embodiments, a route is navigated via multiplemodes of transportation using a vehicle navigation system and a mobilenavigation system.

2. Background Art

Various examples exist of tools that provide route information based ontravel via multiple modes of transport.

For example, U.S. Pat. No. 6,834,229 issued to Rafiah et al. disclosesan integrated journey planner. The integrated journey plannerdeconstructs user enquiries into information requests, each specifying ajourney part using a single transport mode, e.g., rail, car or coach.The planner sends each request to one of a plurality of local andon-line databases, each corresponding to a different transport mode.Responses from the databases are reconstructed into multi-modal traveloption(s) for the user specified journey, incorporating differenttransport modes. The multi-modal travel option(s) incorporates timetabletravel information and non-timetable travel information. Also, a usercan specify a geographical location and a transport mode to find themost suitable terminals and services for uni-modal point to pointtravel.

U.S. Application Publication No. 2006/0241857 discloses a navigationsystem, route search server, route search method, and route searchprogram. A navigation system enables searching for an optimum routethrough a one-time route searching process where several destination ordeparture locations exist. The navigation system includes a point ofinterest (POI) attribute information database for accumulating POIattribute information, a network data edit means and a virtual nodesetup means. The navigation system determines whether there is aplurality of POIs in a certain departure location and/or a destinationlocation by making reference to relevant data in the POI attributeinformation database. If there are several POIs, the virtual node setupmeans sets up a virtual node connected to each node of the plurality ofPOIs through links having identical link cost. The network data editmeans then adds the virtual node to the searching network data, and aroute search means functions to search for routes using the searchingnetwork data containing the added virtual node.

SUMMARY

One aspect include a method for route navigation using multiple modes oftransportation. Route information may be received for generating anavigation route comprising multiple modes of transportation to adestination. GPS data may also be received. A navigation route to thedestination across the multiple modes of transportation may bedetermined. This route may be updated as the route is traversed. Forexample, and without limitation, a routing change may be received andthe navigation route for each of the multiple modes of transportationmay be determined based on the routing change. The navigation routeacross the multiple modes of transportation may be output based on theGPS data.

Non-route transportation information (including, but not limited to,time information and cost information) for multiple transport types mayalso be received. As such, the navigation route may be output basedadditionally on the non-route transportation information.

In some embodiments, the navigation route may be output on a firstdevice communicating with a second device. An event defining a change inthe mode of transportation (such as, and without limitation, a key-offevent, a gear change event, a key-on event, or a proximity to atransport change location) may be received on the first device. Based onthe event, the navigation route may be output on the second device. Thefirst or second device may be an in-vehicle navigation system or anomadic device.

In some embodiments, traveler criteria (such as travel time, scenicroute, or ease of travel) may be received and the navigation route maybe additionally determined based on the traveler criteria.

Another aspect may include a method for route navigation using multiplemodes of transport. An input on a first device may be received whichdefines a destination point. Based on the destination point, anavigation route may be determined on the first device which may includeinstructions for travelling by multiple modes of transport. Thenavigation route may be output on the first device according to at leastone mode of transport. In response to an event defining a change in themode of transport, determining if routing of the navigation route isperformed on a second device. The navigation route may be output on thefirst device or the second device.

In some embodiments, route information for each of the multiple modes oftransport may be received based on the destination point from multipletransport information sources. These may be publicly available sources.In this case, the navigation route may be additionally determined basedon the route information from the multiple transport informationsources.

The method may also include establishing a data connection with thesecond device. In this case, data representing the navigation route maybe transferred to the second device over a data connection (such as aBLUETOOTH connection, WiFi connection, or cellular connection) inresponse to the event and the navigation route output on the seconddevice.

An additional aspect may include a computer-program product for routinga navigation route that comprises multiple modes of transport. One ormore inputs (such as GPS data and/or a destination) may be receiveddefining data for determining a multi-modal navigation route.Additionally, transport-specific route information andtransport-specific non-route information may be received for two or moremodes of transport. The multi-modal navigation route may be determinedbased on the transport-specific route information and transport-specificnon-route information and the one or more inputs.

An event defining a change from a first mode of transport to a secondmode of transport may be received. The multi-modal navigation route maybe output for the second mode of transport.

The route information and the non-route information may includes, but isnot limited to, timetables, cost information, map data, train lineinformation, bus line information, traffic information, GPS locationdata, road and highway information, route corridor information,elevation information, airline and airport information, indoor and/oroutdoor foot paths, and bike paths.

These and other aspects will be better understood in view of theattached drawings and following detailed description of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

The figures identified below are illustrative of some embodiments of theinvention. The figures are not intended to be limiting of the inventionrecited in the appended claims. The embodiments, both as to theirorganization and manner of operation, together with further object andadvantages thereof, may best be understood with reference to thefollowing description, taken in connection with the accompanyingdrawings, in which:

FIG. 1 illustrates a block topology of a vehicle computing system;

FIG. 2 illustrates a block topology of a system that generates andupdates route information for navigating via multiple modes oftransport;

FIG. 3 illustrates a process for determining and presenting routeinformation for navigating via multiple modes of transport;

FIG. 4 illustrates a process for generating a navigation route formultiple modes of transport according to another embodiment; and

FIG. 5 illustrates a process for generating a navigation route formultiple modes of transport according to another embodiment.

DETAILED DESCRIPTION

Detailed embodiments of the invention are disclosed herein. However, itis to be understood that the disclosed embodiments are merely exemplaryof an invention that may be embodied in various and alternative forms.Therefore, specific functional details disclosed herein are not to beinterpreted as limiting, but merely as a representative basis for theclaims and/or as a representative basis for teaching one skilled in theart to variously employ the present invention.

In various cities across the world, and particularly urban cities, usingmultiple modes of transport to reach a destination is not uncommon. Anindividual who lives in a suburb, but wants to see a museum in the city,may take a car, train, and walk to reach the museum from his or herhome. Similarly, multiple modes of transport may be used as part ofdomestic or international travel. For example, after a traveler arrivesat an arrival port (whether it be a train station, airport, bus station,etc.), the traveler may need to use at least one additional mode oftransport to get to the final destination (e.g., a hotel).

When travelling via a single mode of transport, a navigation system is ahandy tool to use for various reasons. Vehicles, and even some mobilephones, come equipped with a navigation system to assist the traveler intravelling from one location to another. Mobile phone users can use thephone's navigation system in a vehicle. Alternatively, the user can useit when walking to a destination. Among other reasons, uni-modalnavigation systems make travelling more convenient. For example, theuser inputs a destination address and the navigation system will routethe use to the destination via the single mode of transport withoutfurther input from the traveler.

However, this convenience is lost when the traveler is using multiplemodes of transport. The user may have to input multiple destinationaddresses for each mode of transport before reaching the finaldestination. Additionally, there may be non-navigation relatedinformation (such as timetables, train lines, etc.) that the user mayneed as part of the multi-modal travel which may not be automaticallydetermined as part of the navigation route. Since vehicles and nomadicdevices, such as mobile phones, are equipped to have navigation systems,leveraging this functionality to provide multi-modal navigation to atraveler would be useful.

FIG. 1 illustrates an example block topology for a vehicle basedcomputing system 1 for a vehicle 31. A vehicle enabled with avehicle-based computing system may contain a visual front end interface4 located in the vehicle. The user may also be able to interact with theinterface if it is provided, for example, with a touch sensitive screen.In another illustrative embodiment, the interaction occurs through,button presses, audible speech and speech synthesis.

In the illustrative embodiment 1 shown in FIG. 1, a processor 3 controlsat least some portion of the operation of the vehicle-based computingsystem. Provided within the vehicle, the processor allows onboardprocessing of commands and routines. Further, the processor is connectedto both non-persistent 5 and persistent storage 7. In this illustrativeembodiment, the non-persistent storage is random access memory (RAM) andthe persistent storage is a hard disk drive (HDD) or flash memory.

The processor is also provided with a number of different inputsallowing the user to interface with the processor. In this illustrativeembodiment, a microphone 29, an auxiliary input 25 (for input 33), a USBinput 23, a GPS input 24 and a BLUETOOTH input 15 are all provided. Aninput selector 51 is also provided, to allow a user to swap betweenvarious inputs. Input to both the microphone and the auxiliary connectoris converted from analog to digital by a converter 27 before beingpassed to the processor.

Outputs to the system can include, but are not limited to, a visualdisplay 4 and a speaker 13 or stereo system output. The speaker isconnected to an amplifier 11 and receives its signal from the processor3 through a digital-to-analog converter 9. Output can also be made to aremote BLUETOOTH device such as PND 54 or a USB device such as vehiclenavigation device 60 along the bi-directional data streams shown at 19and 21 respectively.

In one illustrative embodiment, the system 1 uses the BLUETOOTHtransceiver 15 to communicate 17 with a user's nomadic device 53 (e.g.,cell phone, smart phone, PDA, etc.). The nomadic device can then be usedto communicate 59 with a network 61 outside the vehicle 31 through, forexample, communication 55 with a cellular tower 57. In some embodiments,tower 57 may be a WiFi access point.

Exemplary communication between the nomadic device and the BLUETOOTHtransceiver is represented by signal 14.

Pairing a nomadic device (ND) 53 and the BLUETOOTH transceiver 15 can beinstructed through a button 52 or similar input. Accordingly, the CPU isinstructed that the onboard BLUETOOTH transceiver will be paired with aBLUETOOTH transceiver in a nomadic device.

Data may be communicated between CPU 3 and network 61 utilizing, forexample, a data-plan, data over voice, or DTMF tones associated withnomadic device 53. Alternatively, it may be desirable to include anonboard modem 63 having antenna 18 in order to communicate 16 databetween CPU 3 and network 61 over the voice band. The nomadic device 53can then be used to communicate 59 with a network 61 outside the vehicle31 through, for example, communication 55 with a cellular tower 57. Insome embodiments, the modem 63 may establish communication 20 with thetower 57 for communicating with network 61. As a non-limiting example,modem 63 may be a USB cellular modem and communication 20 may becellular communication.

In one illustrative embodiment, the processor is provided with anoperating system including an API to communicate with modem applicationsoftware. The modem application software may access an embedded moduleor firmware on the BLUETOOTH transceiver to complete wirelesscommunication with a remote BLUETOOTH transceiver (such as that found ina nomadic device).

In another embodiment, nomadic device 53 includes a modem for voice bandor broadband data communication. In the data-over-voice embodiment, atechnique known as frequency division multiplexing may be implementedwhen the owner of the nomadic device can talk over the device while datais being transferred. At other times, when the owner is not using thedevice, the data transfer can use the whole bandwidth (300 Hz to 3.4 kHzin one example).

If the user has a data-plan associated with the nomadic device, it ispossible that the data-plan allows for broad-band transmission and thesystem could use a much wider bandwidth (speeding up data transfer). Instill another embodiment, nomadic device 53 is replaced with a cellularcommunication device (not shown) that is installed to vehicle 31. In yetanother embodiment, the ND 53 may be a wireless local area network (LAN)device capable of communication over, for example (and withoutlimitation), an 802.11g network (i.e., WiFi) or a WiMax network.

In one embodiment, incoming data can be passed through the nomadicdevice via a data-over-voice or data-plan, through the onboard BLUETOOTHtransceiver and into the vehicle's internal processor 3. In the case ofcertain temporary data, for example, the data can be stored on the HDDor other storage media 7 until such time as the data is no longerneeded.

Additional sources that may interface with the vehicle include apersonal navigation device 54, having, for example, a USB connection 56and/or an antenna 58; or a vehicle navigation device 60, having a USB 62or other connection, an onboard GPS device 24, or remote navigationsystem (not shown) having connectivity to network 61.

Further, the CPU could be in communication with a variety of otherauxiliary devices 65. These devices can be connected through a wireless67 or wired 69 connection. Also, or alternatively, the CPU could beconnected to a vehicle based wireless router 73, using for example aWiFi 71 transceiver. This could allow the CPU to connect to remotenetworks in range of the local router 73.

FIG. 2 is a block topology of a navigation routing system for multiplemodes of transport. A multi-modal routing engine 100 may be used fordetermining a multi-modal navigation route. It will be appreciated thatthere may more than one routing engine for determining and navigating amulti-modal route. The routing engine 100 may comprise one or morenavigation algorithms for making the navigation determination. Therouting engine 100 may receive route information (described below) anddecompress or unpack this route information to generate a route.Non-route information (described below) may also be received by therouting engine 100 to generate a route. Accordingly, the route may begenerated based on a combination of information such as (and withoutlimitation), GPS information, traffic information, schedules andtimetables, elevation information, and/or distance information (e.g., infeet, meters, miles, etc.). Further details of these navigationalgorithms will be described below with respect to FIGS. 3-5.

The routing engine 100 may include instructions for outputting thenavigation route as speech (via a text-to-speech (TTS) engine),graphical illustration, and/or text. The routing engine 100 maycommunicate with a separate engine (such as, and without limitation, aTTS engine or display engine) on the VCS 1 for outputting themulti-modal route. Additionally, the routing engine 100 may include, orcommunicate with, a geocoding engine for resolving GPS data into a usercomprehendible form.

The routing engine 100 may be implemented on the VCS 1 and communicatedata with the vehicle navigation device 60 or the PND 54. Data exchange112 a, 112 b between the routing engine 100 and the VCS 1 may bebi-directional. Additionally or alternatively, the routing engine 100may be implemented on a remote server (which may be at cloud 61) andfunction as a cloud-based service. Data exchange 110 a, 110 b betweenthe routing engine 100 and the server may also be bi-directional. Inthis embodiment, the routing engine 100 may determine the navigationroute and transmit the route to the VCS 1 for output to a vehicleoccupant. Data communicated to the VCS 1 may be communicated throughwired (e.g., and without limitation, USB) or wireless (e.g., and withoutlimitation, WiFi) communication as described above. In one embodiment,the cloud 61 may comprise a service delivery network.

As described above, a nomadic device 53 may communicate with the VCS 1.When disconnected from the VCS 1, the ND 53 may be used to navigatenon-vehicle, multi-modal routes. As such, the ND 53 may also haveinstalled a multi-modal routing engine 122. This multi-modal routingengine 122 may be installed by a user to the ND 53 from the Internet(such as from a mobile application store or a website) or via physicalmediums such as a USB drive. The ND 53 may include the necessary toolsknown in the art for navigating a route (such as a GPS system).

The routing engine 100 may exchange data and instructions to the ND 53via an application programming interface (API). APIs may be implementedon the VCS 1, the NDS 53, or both. Additionally, data may be transmittedusing a general transport protocol. In one embodiment, the generaltransport protocol may facilitate the exchange of data with NDs havingdifferent communication protocols.

Navigation route information transferred between the VCS 1 and the ND 53to navigate a multi-modal route (e.g., vehicle and foot) may be based onthe detection of a transport change event. A transport change event maybe an occurrence that identifies a change in a mode of transport.Examples may include, but are not limited to, vehicle-based events(including, but not limited to, key-off, key-on, and a gear change), aconnection event between a VCS 1 and the ND 53, a user input event, anda GPS location of a GPS-enabled device (e.g., a mobile phone or vehiclenavigation system). The following illustrations provide further detailsof these examples. It will be appreciated that these example arenon-limiting, non-exhaustive, and provided for illustration. Further, itwill be appreciated that the transport change events may occur incombination or individually. Details of determining/calculating anavigation route is described with respect to FIGS. 3-5.

Example 1 Key-Off Even

A route to a destination requires that a user (also referred to hereinas “a traveler”) travel by car and foot. The portion of the route thatcan be travelled by car is navigated by the driver with the in-vehiclenavigation system. The in-vehicle navigation system may be built-in ormay be a peripheral. At a key-off event, the data representing thenavigation route is transmitted to the driver's mobile phone. The usermay then continue to navigate the route by foot with the mobile phone.

Example 2 Key-On Event; Connection Event; Gear Change Event

The user (from the above example), heading home, uses the mobile phone'snavigation system to walk to the vehicle. After connecting the phone tothe VCS 1, at a key-on event, the navigation route is transmitted to thenavigation device 54 or 60 of the VCS 1 and output to the user.Alternatively, at a connection event, such as when a connection isestablished with the VCS 1 via a wired or wireless connection, thenavigation route may be transmitted to the VCS 1. In yet an alternativeembodiment, the navigation route may be transmitted to the VCS 1 at agear change event (e.g., and without limitation, changing from “Park” to“Drive”). One or more messages may be transmitted over the vehiclenetwork (such as, and without limitation, a CAN bus) for outputting thenavigation route from the phone to the VCS 1.

Example 3 User Input Event

A user input event may include a tactile input (such as, and withoutlimitation, a touchscreen input, a button press, a keypad press, or acapacitive input) and/or a voice input. As an example, a route to adestination requires that a user travel by car, bus, train, and foot.The portion of the route that can be travelled by car is navigated bythe driver with the in-vehicle navigation system. At the user inputevent, the data representing the navigation route may be transmitted tothe driver's mobile phone.

The user may then continue to navigate the route with the mobile phone.At each additional mode of transport (bus, train, and foot), the usermay submit the user input to navigate the route by each additional modeof transport. For example, if the navigation route says to ride “Bus X”and “Bus Y” to reach the train station, a user input event may bereceived on the mobile phone when the traveler rides Bus X signifyingthat the user is riding “Bus X.” The navigation route on the mobilephone may then display the additional modes of transport (e.g., Bus Y,one or more train numbers, and/or walking directions). In someembodiments, additional information may be shown including, but notlimited to, distance information, timetables, and fare costs).

On return to the vehicle, the user may submit a user input to signalthat the user is in the vehicle and to run the vehicle-based navigationroute in the vehicle.

Example 4 GPS Location

There may be one or more ways of determining a transport change eventbased on GPS location information. As one example, on return to thevehicle (from the above example), when the user is dropped off at theBus X drop off point, a comparison may be made between the current GPSlocation (e.g., based on coordinates) of the user (or a “pick up point”signifying the starting point for the additional mode of transport orthe final destination) and the ending GPS location of the vehicle (orthe last mode of transport). A look up table may include the GPScoordinates of each location. The look up table may be createddynamically when the multi-modal route is generated. If a comparisonshows a match or near match in GPS locations (e.g., between the drop offpoint and the pick up point), the match or near match may be recognizedand the directions relating to the next mode of transport presented tothe user.

As another example, when the vehicle is within a certain distance (orproximity) from the Bus X pick up point, a background transfer of themulti-modal navigation route to the mobile device may occur. Thus, therouting engine 100 may use the GPS location data to determine thedistance (which may include elevation information) to the next mode oftransport and, when a distance threshold is reached or passed, thenavigation route may be transferred from one device to another. If thetransfer is from an in-vehicle navigation system to a ND 53, thetransfer may be made to any vehicle occupant's phone that is connectedto the VCS 1. At or near the Bus X pick up point, the navigation routemay be automatically presented to the user on the ND 53 and run inparallel on both devices. Alternatively, the Bus X navigation route maybe transferred and/or presented in response to a user input (e.g., inresponse to a request from the routing engine 100 whether to transferand/or present the new route on the ND 53).

Referring back to FIG. 2, routing engine 100 may use information fromone or more transport information sources 102, 104, 106, 108 to generatethe multi-modal navigation routes. The transport information sources102, 104, 106, 108 may correspond to the one or more modes of transport.The transport information sources 102, 104, 106, 108 may additionally oralternatively include information such as weather, elevationinformation, and the like. The information sources 102, 104, 106, 108may be public websites (or other publicly available sources). Thepublicly available source may or may not require a subscription toaccess the information.

Transportation information may be route information and non-routeinformation utilized in determining the navigation route. Non-limitingexamples of transportation information include, but are not limited to,timetables and schedules, price of fares, price of tolls, map data,train line information, bus line information, traffic information, GPSlocation data, road and highway information, route corridor information,elevation information, airline and airport information, indoor and/oroutdoor foot paths, bike paths and bike lanes, and the like. As such,communication lines 114, 116, 118, and 120 may be direct links to thewebsites via the Internet.

In some embodiments, the information sources 102, 104, 106, 108 may beone or more databases that store the transportation information. In thiscase, communication 114, 116, 118, and 120 may be any wired or wirelesscommunication with databases 102, 104, 106, 108 that are known in theart. The databases may be in communication with the public websites toreceive updates. Alternatively or additionally, the databases may beupdated manually.

It will be appreciated that the various embodiments described herein maybe used during an actual, live navigation event. Alternatively, thevarious embodiments can be used in a testing environment (e.g., duringsimulation of a navigation event).

FIG. 3 illustrates a process for generating and presenting a navigationroute for multiple modes of transport. It will be appreciated that thedisclosure and arrangement of FIG. 3 may be modified or re-arranged tobest fit a particular implementation of the various embodiments of theinvention. Further, for simplicity and clarity, FIGS. 3-5 are describedin the context of the user beginning a navigation route in a vehicle.However, the process is not limited to this scenario such that thestarting point of the navigation route may be, alternatively, outside ofthe vehicle.

One or more points of travel may be received as illustrated in block200. The point(s) of travel may be received as a destination point. Thedestination point may be received as an address, point of interest,intersection, city center, and the like. In this embodiment, thestarting address may be automatically determined based on a GPS locationof the user. Alternatively, a departing point of travel and adestination point of travel may be input. The point(s) of travel may beinput using tactile inputs (e.g., on a touch screen display) and/orvoice inputs.

Multi-modal navigation may be automatically activated when a navigationsystem is run. As such, the user may be presented with an option toreceive a uni-modal route or a multi-modal route. A user may select anoption through tactile and/or voice inputs. Alternatively, a user mayhave to separately activate a multi-modal navigation system orapplication. In this embodiment, the multi-modal navigation system canstill operate as a uni-modal navigation system.

Accordingly, a determination may be made whether a route based on thepoint(s) of travel includes a multi-modal navigation route (block 202).If not, a transport information request may be transmitted to a singleinformation source 102, 104, 106, or 108 (block 204). Otherwise, thetransport information request may be transmitted to multiple informationsources (block 206). In one embodiment, the traveler may select themodes of transport to utilize. In this embodiment, the transportinformation request may be transmitted to the selected modes oftransport.

The transport information request may include instructions orinformation for obtaining transportation information used by routingengine 100 for determining a navigation route. These instructions orinformation may include, but not limited to, data pertaining to thepoint(s) of travel, the traveler's GPS location or both. In someembodiments, the transportation information request may additionallyinclude a user's travel criteria (described below).

The transportation information may be received at the routing engine 100from the information resource(s) as illustrated in block 208. Thetransportation information may be received based on the transportationinformation request. Non-exhaustive and non-limiting examples oftransportation information are provided above. As an example, a userwith a vehicle having a solar panel roof may want a route that maximizestime in the sun. Accordingly, the traveler's destination address and atravel criterion (such as optimize route for angle of sun) may betransmitted to the transportation information sources. The routingengine 100 may then receive information from the transportationinformation sources providing a multi-modal route with thetransportation information and the weather information.

The navigation route may be determined/calculated by the routing engine100 (block 210). The routing engine 100 may have at least one algorithmfor determining a navigation route. FIGS. 4 and 5 illustrate algorithmsfor determining a multi-modal navigation route. However, it will beappreciated that at least some of the operation illustrated in FIGS. 4and 5 may alternatively or additionally be applied in a navigation routedetermination for a single mode of transport (i.e., a uni-modalnavigation route).

The route information received may be used to generate a navigationroute for each mode of transport when the transportation information isreceived from the transport information source(s) (block 300). One ormore navigation routes may be generated for each transport type (block302). For example, the routing engine 100 may generate route(s) for eachof vehicle, train, foot, airplane, and/or bus. In one embodiment, eachroute may be generated at the information source(s) 102, 104, 106, 108and the routing engine may optimize these routes as described below.

Each route may be optimized. Optimization of the route may be based on atraveler's travel criteria. Traveler criteria may include, but are notlimited to, travel time, scenic route, safe route, city route, and easeof travel (e.g., and without limitation, avoiding complicated roadroutes, avoiding too many train, bus, and airplane transfers, etc.). Thetraveler may input the traveler criteria when entering the point(s) oftravel. In some embodiments, the traveler may input the travelercriteria at any time. As such, if the multi-modal route has already beengenerated, the route may be updated based on the traveler criteria. Infurther embodiments, if the user does not enter traveler criteria, adefault criterion may be assigned by the routing engine (e.g., easiestroute). In yet further embodiments, the determination in block 304 maynot occur such that the transport-specific route is always optimizedbecause the route(s) are generated based on the traveler criteria.

If a determination is made that the route for each transport type doesnot account for traveler criteria (block 304), the route may bere-routed for each transport type (block 302) until each route isoptimized based on the traveler criteria. Once complete, each transportspecific route may be compared by the routing engine (block 306).

Based on the comparison, a determination may be made whether there isonly a single mode of transport for a portion of the route (block 308).For example, for certain portions of the route, the traveler may only beable to travel by car, foot, or airplane. If so, the single mode oftransport is assigned to the portion(s) of the route capable of beingtraveled only be that single mode of transport (block 310). Theuni-modal portions of the route may be stored in memory of the VCS 1(block 312).

For the portions of the route having multiple transport type options(block 308), the routing engine 100 may identify the available modes oftransport (block 314). Non-route information may be used to filter theroutes for the different modes of transport (block 316). The routes maybe filtered based on the non-route information (block 318). Further, thefiltering process may be performed with respect to the traveler criteriadescribed above. Non-limiting and non-exhaustive examples of non-routeinformation are provided above. In one embodiment, the non-routeinformation may alternatively be used as part of the optimizationprocess (block 304).

In one embodiment, the filtering process may be based on a ranking. Forexample, and without limitation, the routes may be ranked based on time,cost, distance, difficulty of travel, etc. determined from the non-routeinformation for each transport type. The ranking information may bepreprogrammed to the routine engine.

The multi-modal route is generated as illustrated in block 320. As apart of generating the multi-modal route, the partial routes assignedwith the single mode of transport (block 312) may be received by therouting engine 100. The multi-modal route may then be transmitted andpresented to the traveler (block 212). The route may be presentedvisually (including text and/or graphics) and/or audibly.

FIG. 5 illustrates a process for determining a multi-modal navigationroute according to another embodiment. In some geographic locations, atraveler can use multiple highways, multiple bus lines, multiple trainlines, multiple foot paths, or other transportation that has multipleoptions for travelling a route. As such, the navigation routedetermination may be additionally or alternatively made according tothis scenario.

The route information received from the information source(s) may bereceived with the various options for each transport type (block 400).For each mode of transport, the routing algorithm may combine at leastone option for one mode of transport with another option for anothermode of transport (block 402). For some routes, there may be one optionfor a segment of the route. The routing algorithm may also generate oneor more different combinations of routing possibilities for eachtransport type based on the various options (block 404). Thus, there maybe multiple multi-modal routes for the traveler to take in reaching adestination.

A determination may be made whether the multiple multi-modal navigationoptions are optimized for the traveler (block 406). Non-routeinformation may be used to filter or optimize the navigation route(s)combinations/options according to traveler criteria (block 408). Thismay include the ranking process described above. The multi-modal routemay be generated as illustrated in block 410 for transmission andpresentation to the user (block 212). The presentation may be textual,graphical, and/or audible. The route may be transmitted in one or moreforms including, but not limited to, an electronic mail message, anSMS/text message, graphical images, speech based messages, and the like.

Referring back to FIG. 3, the multi-modal navigation route is presentedto the traveler (block 212). At a point while routing the traveler alongthe navigation route (block 214), the routing engine 100 may determineif a transport change event has occurred (block 216). Examples oftransport change events are provided above. In one embodiment, there maybe a software application installed on the VCS 1 that may make thedetermination.

At least part of the routing may be based on the GPS position of theGPS-enabled device (i.e., the VCS 1 or the nomadic device 53). Forexample, GPS data may be used for routing along a vehicle-based routeand a foot path, but not when on a train and a bus. As such, detours androute changes by the traveler may be determined. The navigation routemay be re-routed based on the route change. It will be appreciated thatthis example is for illustration and that GPS data may be utilized inany or all segments of the multi-modal navigation route withoutdeparting from the scope and spirit of the invention.

If there is a navigation route change, transportation information may beupdated based on the changes in the navigation route. The content of theinformation sources 102, 104, 106, and 108 may be dynamic such that therouting engine 100 may receive updated information from the informationsource(s) 102, 104, 106, 108 when there is a routing change. This mayinclude receiving both route transportation information and non-routetransportation information. Accordingly, routing engine 100 may monitorif a detour from the multi-modal navigation route causes a change in thenon-route information. As an example, a detour by a traveler may causethe traveler to miss the given train time. As such, the routing engine100 may then provide the traveler with the next available time. It willbe appreciated that the updating process may be performed by a separateengine communicating with the routing engine 100.

At the transport change event, the device that presents the navigationroute to the traveler may change between two or more devices. Forexample, the display may move from display 4 to a display of the ND 53.If there is no transport change event, there may not be a device change(block 218). As such, routing of the multi-modal navigation route maycontinue on the same device where the point(s) of travel was entered orthe navigation route began.

If there is a transport change event, a further determination may bemade whether a second device is detected (block 220). The navigationroute may be presented on this second device if there is a transportchange event. If there is not a second device, there may not be a devicechange and routing of the navigation route may continue for the new modeof transport on the same device.

If there is a second device, the navigation route may be transmitted tothe second device (block 222). The navigation route may be presented tothe traveler, and routing of the navigation route accomplished (block214), from this second device. The presentation may be visual and/oraudible. The route may be transmitted in one or more forms including,but not limited to, an electronic mail message, an SMS/text message,graphical images, speech based messages, and the like. The navigationroute may be transmitted to the second device through wired (e.g., andwithout limitation, USB) or wireless communication (e.g., and withoutlimitation, BLUETOOTH, WiFi, cellular, or data over voice).

In some embodiments, the navigation route may be transmitted to aportable memory device including, but not limited to, a USB drive, amemory stick, a secure digital (SD) card, a compact flash (CF) card, andthe like. In this embodiment, the portable memory device may store thenavigation route. When the portable memory device is connected to amemory device reader, the route may be transmitted to the device (e.g.,and without limitation, a nomadic device 53 or the VCS 1).

While exemplary embodiments are illustrated and described above, it isnot intended that these embodiments illustrate and describe allpossibilities. Rather, the words used in the specification are words ofdescription rather than limitation, and it is understood that variouschanges may be made without departing from the spirit and scope of theinvention.

What is claimed:
 1. A computer-implemented method comprising: Receivingdestination information at a vehicle computing system (VCS); determininga route to the destination, wherein different portions of the route arebased on different modes of transportation; outputting at least auser-driven portion of the route on a vehicle display; detecting avehicle event defining an end to the user-driven portion of the route;and outputting a remaining non-user-driven route on a portable devicebased on the event detection.
 2. The computer-implemented method ofclaim 1 further comprising: receiving non-route transportationinformation for multiple transport types; and outputting the navigationroute based additionally on the non-route transportation information. 3.The computer-implemented method of claim 2 wherein the non-routetransportation information includes at least one of time information andcost information.
 4. The computer-implemented method of claim 1 whereindetermining a route further comprises: receiving a routing change; anddetermining a route for each of the different modes of transportationbased on the routing change.
 5. The computer-implemented method of claim1 wherein the vehicle event is a key-off event, a gear change event, ora key-on event.
 6. The computer-implemented method of claim 1 whereinthe vehicle event is a proximity to a transport change location.
 7. Thecomputer-implemented method of claim 1 further comprising presenting theroute as speech, graphical images, an SMS message or an electronic mailmessage.
 8. The computer-implemented method of claim 1 furthercomprising: receiving traveler criteria; and determining the routeadditionally based on the traveler criteria.
 9. The computer-implementedmethod of claim 8 wherein the traveler criteria includes at least one oftravel time, scenic route, or ease of travel.
 10. A computer-implementedmethod comprising: receiving input on a first device defining adestination; determining a route to the destination on the first device,including instructions for travelling by multiple modes of transport;outputting the route on vehicular device, according to a user-drivenportion of the route; receiving a vehicular event defining an end to theuser-driven portion of the route; and in response to the event,outputting the navigation route on a portable device.
 11. Thecomputer-implemented method of claim 10 wherein the event includes akey-off event, a key-on event, or a gear change.
 12. Thecomputer-implemented method of claim 10 further comprising: receivingroute information for each of the multiple modes of transport based onthe destination point from multiple transport information sources; anddetermining the route additionally based on the route information fromthe multiple transport information sources.
 13. The computer-implementedmethod of claim 12 wherein the multiple transport information sourcesare publicly available sources.
 14. The computer-implemented method ofclaim 10 establishing a data connection with the portable device;transferring data representing the navigation route to the portabledevice over the data connection in response to the event; and.
 15. Thecomputer-implemented method of claim 14 wherein the data connection isat least one of a BLUETOOTH connection, WiFi connection, or cellularconnection.
 16. The computer-implemented method of claim 10 furthercomprising: receiving GPS data; and outputting the navigation routebased on the GPS data.
 17. A tangible computer-program product embodiedin at least one computer-readable medium, having computer-readableinstructions programmed for: receiving input on a first device defininga destination; determining a route to the destination on the firstdevice, including instructions for travelling by multiple modes oftransport; outputting the route on vehicular device, according to auser-driven portion of the route; receiving a vehicular event definingan end to the user-driven portion of the route; and in response to theevent, outputting the navigation route on a portable device.